home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1067.txt < prev    next >
Text File  |  1994-08-01  |  68KB  |  1,851 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            J. Case
  8. Request for Comments: 1067          University of Tennessee at Knoxville
  9.                                                                 M. Fedor
  10.                                                           NYSERNet, Inc.
  11.                                                           M. Schoffstall
  12.                                         Rensselaer Polytechnic Institute
  13.                                                                 J. Davin
  14.                                                            Proteon, Inc.
  15.                                                              August 1988
  16.  
  17.  
  18.                   A Simple Network Management Protocol
  19.  
  20.                            Table of Contents
  21.  
  22.    1. Status of this Memo ...................................    2
  23.    2. Introduction ..........................................    2
  24.    3. The SNMP Architecture .................................    4
  25.    3.1 Goals of the Architecture ............................    4
  26.    3.2 Elements of the Architecture .........................    4
  27.    3.2.1 Scope of Management Information ....................    5
  28.    3.2.2 Representation of Management Information ...........    5
  29.    3.2.3 Operations Supported on Management Information .....    6
  30.    3.2.4 Form and Meaning of Protocol Exchanges .............    7
  31.    3.2.5 Definition of Administrative Relationships .........    7
  32.    3.2.6 Form and Meaning of References to Managed Objects ..   11
  33.    3.2.6.1 Resolution of Ambiguous MIB References ...........   11
  34.    3.2.6.2 Resolution of References across MIB Versions......   11
  35.    3.2.6.3 Identification of Object Instances ...............   11
  36.    3.2.6.3.1 ifTable Object Type Names ......................   12
  37.    3.2.6.3.2 atTable Object Type Names ......................   12
  38.    3.2.6.3.3 ipAddrTable Object Type Names ..................   13
  39.    3.2.6.3.4 ipRoutingTable Object Type Names ...............   13
  40.    3.2.6.3.5 tcpConnTable Object Type Names .................   13
  41.    3.2.6.3.6 egpNeighTable Object Type Names ................   14
  42.    4. Protocol Specification ................................   15
  43.    4.1 Elements of Procedure ................................   16
  44.    4.1.1 Common Constructs ..................................   18
  45.    4.1.2 The GetRequest-PDU .................................   19
  46.    4.1.3 The GetNextRequest-PDU .............................   20
  47.    4.1.3.1 Example of Table Traversal .......................   22
  48.    4.1.4 The GetResponse-PDU ................................   23
  49.    4.1.5 The SetRequest-PDU .................................   24
  50.    4.1.6 The Trap-PDU .......................................   26
  51.    4.1.6.1 The coldStart Trap ...............................   27
  52.    4.1.6.2 The warmStart Trap ...............................   27
  53.    4.1.6.3 The linkDown Trap ................................   27
  54.    4.1.6.4 The linkUp Trap ..................................   27
  55.  
  56.  
  57.  
  58. Case, Fedor, Schoffstall, & Davin                               [Page 1]
  59.  
  60. RFC 1067                          SNMP                       August 1988
  61.  
  62.  
  63.    4.1.6.5 The authenticationFailure Trap ...................   27
  64.    4.1.6.6 The egpNeighborLoss Trap .........................   27
  65.    4.1.6.7 The enterpriseSpecific Trap ......................   28
  66.    5. Definitions ...........................................   29
  67.    6. Acknowledgements ......................................   32
  68.    7. References ............................................   33
  69.  
  70. 1.  Status of this Memo
  71.  
  72.    This memo defines a simple protocol by which management information
  73.    for a network element may be inspected or altered by logically remote
  74.    users.  In particular, together with its companion memos which
  75.    describe the structure of management information along with the
  76.    initial management information base, these documents provide a
  77.    simple, workable architecture and system for managing TCP/IP-based
  78.    internets and in particular the Internet.
  79.  
  80.    This memo specifies a draft standard for the Internet community.
  81.    TCP/IP implementations in the Internet which are network manageable
  82.    are expected to adopt and implement this specification.
  83.  
  84.    Distribution of this memo is unlimited.
  85.  
  86. 2.  Introduction
  87.  
  88.    As reported in RFC 1052, IAB Recommendations for the Development of
  89.    Internet Network Management Standards [1], the Internet Activities
  90.    Board has directed the Internet Engineering Task Force (IETF) to
  91.    create two new working groups in the area of network management.  One
  92.    group is charged with the further specification and definition of
  93.    elements to be included in the Management Information Base (MIB).
  94.    The other is charged with defining the modifications to the Simple
  95.    Network Management Protocol (SNMP) to accommodate the short-term
  96.    needs of the network vendor and operations communities, and to align
  97.    with the output of the MIB working group.
  98.  
  99.    The MIB working group has produced two memos, one which defines a
  100.    Structure for Management Information (SMI) [2] for use by the managed
  101.    objects contained in the MIB.  A second memo [3] defines the list of
  102.    managed objects.
  103.  
  104.    The output of the SNMP Extensions working group is this memo, which
  105.    incorporates changes to the initial SNMP definition [4] required to
  106.    attain alignment with the output of the MIB working group.  The
  107.    changes should be minimal in order to be consistent with the IAB's
  108.    directive that the working groups be "extremely sensitive to the need
  109.    to keep the SNMP simple."  Although considerable care and debate has
  110.    gone into the changes to the SNMP which are reflected in this memo,
  111.  
  112.  
  113.  
  114. Case, Fedor, Schoffstall, & Davin                               [Page 2]
  115.  
  116. RFC 1067                          SNMP                       August 1988
  117.  
  118.  
  119.    the resulting protocol is not backwardly-compatible with its
  120.    predecessor, the Simple Gateway Monitoring Protocol (SGMP) [5].
  121.    Although the syntax of the protocol has been altered, the original
  122.    philosophy, design decisions, and architecture remain intact.  In
  123.    order to avoid confusion, new UDP ports have been allocated for use
  124.    by the protocol described in this memo.
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Case, Fedor, Schoffstall, & Davin                               [Page 3]
  171.  
  172. RFC 1067                          SNMP                       August 1988
  173.  
  174.  
  175. 3.  The SNMP Architecture
  176.  
  177.    Implicit in the SNMP architectural model is a collection of network
  178.    management stations and network elements.  Network management
  179.    stations execute management applications which monitor and control
  180.    network elements.  Network elements are devices such as hosts,
  181.    gateways, terminal servers, and the like, which have management
  182.    agents responsible for performing the network management functions
  183.    requested by the network management stations.  The Simple Network
  184.    Management Protocol (SNMP) is used to communicate management
  185.    information between the network management stations and the agents in
  186.    the network elements.
  187.  
  188. 3.1.  Goals of the Architecture
  189.  
  190.    The SNMP explicitly minimizes the number and complexity of management
  191.    functions realized by the management agent itself.  This goal is
  192.    attractive in at least four respects:
  193.  
  194.       (1)  The development cost for management agent software
  195.            necessary to support the protocol is accordingly reduced.
  196.  
  197.       (2)  The degree of management function that is remotely
  198.            supported is accordingly increased, thereby admitting
  199.            fullest use of internet resources in the management task.
  200.  
  201.       (3)  The degree of management function that is remotely
  202.            supported is accordingly increased, thereby imposing the
  203.            fewest possible restrictions on the form and
  204.            sophistication of management tools.
  205.  
  206.       (4)  Simplified sets of management functions are easily
  207.            understood and used by developers of network management
  208.            tools.
  209.  
  210.    A second goal of the protocol is that the functional paradigm for
  211.    monitoring and control be sufficiently extensible to accommodate
  212.    additional, possibly unanticipated aspects of network operation and
  213.    management.
  214.  
  215.    A third goal is that the architecture be, as much as possible,
  216.    independent of the architecture and mechanisms of particular hosts or
  217.    particular gateways.
  218.  
  219. 3.2.  Elements of the Architecture
  220.  
  221.    The SNMP architecture articulates a solution to the network
  222.    management problem in terms of:
  223.  
  224.  
  225.  
  226. Case, Fedor, Schoffstall, & Davin                               [Page 4]
  227.  
  228. RFC 1067                          SNMP                       August 1988
  229.  
  230.  
  231.       (1)  the scope of the management information communicated by
  232.            the protocol,
  233.  
  234.       (2)  the representation of the management information
  235.            communicated by the protocol,
  236.  
  237.       (3)  operations on management information supported by the
  238.            protocol,
  239.  
  240.       (4)  the form and meaning of exchanges among management
  241.            entities,
  242.  
  243.       (5)  the definition of administrative relationships among
  244.            management entities, and
  245.  
  246.       (6)  the form and meaning of references to management
  247.            information.
  248.  
  249. 3.2.1.  Scope of Management Information
  250.  
  251.    The scope of the management information communicated by operation of
  252.    the SNMP is exactly that represented by instances of all non-
  253.    aggregate object types either defined in Internet-standard MIB or
  254.    defined elsewhere according to the conventions set forth in
  255.    Internet-standard SMI [2].
  256.  
  257.    Support for aggregate object types in the MIB is neither required for
  258.    conformance with the SMI nor realized by the SNMP.
  259.  
  260. 3.2.2.  Representation of Management Information
  261.  
  262.    Management information communicated by operation of the SNMP is
  263.    represented according to the subset of the ASN.1 language [6] that is
  264.    specified for the definition of non-aggregate types in the SMI.
  265.  
  266.    The SGMP adopted the convention of using a well-defined subset of the
  267.    ASN.1 language [6].  The SNMP continues and extends this tradition by
  268.    utilizing a moderately more complex subset of ASN.1 for describing
  269.    managed objects and for describing the protocol data units used for
  270.    managing those objects.  In addition, the desire to ease eventual
  271.    transition to OSI-based network management protocols led to the
  272.    definition in the ASN.1 language of an Internet-standard Structure of
  273.    Management Information (SMI) [2] and Management Information Base
  274.    (MIB) [3].  The use of the ASN.1 language, was, in part, encouraged
  275.    by the successful use of ASN.1 in earlier efforts, in particular, the
  276.    SGMP.  The restrictions on the use of ASN.1 that are part of the SMI
  277.    contribute to the simplicity espoused and validated by experience
  278.    with the SGMP.
  279.  
  280.  
  281.  
  282. Case, Fedor, Schoffstall, & Davin                               [Page 5]
  283.  
  284. RFC 1067                          SNMP                       August 1988
  285.  
  286.  
  287.    Also for the sake of simplicity, the SNMP uses only a subset of the
  288.    basic encoding rules of ASN.1 [7].  Namely, all encodings use the
  289.    definite-length form.  Further, whenever permissible, non-constructor
  290.    encodings are used rather than constructor encodings.  This
  291.    restriction applies to all aspects of ASN.1 encoding, both for the
  292.    top-level protocol data units and the data objects they contain.
  293.  
  294. 3.2.3.  Operations Supported on Management Information
  295.  
  296.    The SNMP models all management agent functions as alterations or
  297.    inspections of variables.  Thus, a protocol entity on a logically
  298.    remote host (possibly the network element itself) interacts with the
  299.    management agent resident on the network element in order to retrieve
  300.    (get) or alter (set) variables.  This strategy has at least two
  301.    positive consequences:
  302.  
  303.       (1)  It has the effect of limiting the number of essential
  304.            management functions realized by the management agent to
  305.            two: one operation to assign a value to a specified
  306.            configuration or other parameter and another to retrieve
  307.            such a value.
  308.  
  309.       (2)  A second effect of this decision is to avoid introducing
  310.            into the protocol definition support for imperative
  311.            management commands:  the number of such commands is in
  312.            practice ever-increasing, and the semantics of such
  313.            commands are in general arbitrarily complex.
  314.  
  315.    The strategy implicit in the SNMP is that the monitoring of network
  316.    state at any significant level of detail is accomplished primarily by
  317.    polling for appropriate information on the part of the monitoring
  318.    center(s).  A limited number of unsolicited messages (traps) guide
  319.    the timing and focus of the polling.  Limiting the number of
  320.    unsolicited messages is consistent with the goal of simplicity and
  321.    minimizing the amount of traffic generated by the network management
  322.    function.
  323.  
  324.    The exclusion of imperative commands from the set of explicitly
  325.    supported management functions is unlikely to preclude any desirable
  326.    management agent operation.  Currently, most commands are requests
  327.    either to set the value of some parameter or to retrieve such a
  328.    value, and the function of the few imperative commands currently
  329.    supported is easily accommodated in an asynchronous mode by this
  330.    management model.  In this scheme, an imperative command might be
  331.    realized as the setting of a parameter value that subsequently
  332.    triggers the desired action.  For example, rather than implementing a
  333.    "reboot command," this action might be invoked by simply setting a
  334.    parameter indicating the number of seconds until system reboot.
  335.  
  336.  
  337.  
  338. Case, Fedor, Schoffstall, & Davin                               [Page 6]
  339.  
  340. RFC 1067                          SNMP                       August 1988
  341.  
  342.  
  343. 3.2.4.  Form and Meaning of Protocol Exchanges
  344.  
  345.    The communication of management information among management entities
  346.    is realized in the SNMP through the exchange of protocol messages.
  347.    The form and meaning of those messages is defined below in Section 4.
  348.  
  349.    Consistent with the goal of minimizing complexity of the management
  350.    agent, the exchange of SNMP messages requires only an unreliable
  351.    datagram service, and every message is entirely and independently
  352.    represented by a single transport datagram.  While this document
  353.    specifies the exchange of messages via the UDP protocol [8], the
  354.    mechanisms of the SNMP are generally suitable for use with a wide
  355.    variety of transport services.
  356.  
  357. 3.2.5.  Definition of Administrative Relationships
  358.  
  359.    The SNMP architecture admits a variety of administrative
  360.    relationships among entities that participate in the protocol.  The
  361.    entities residing at management stations and network elements which
  362.    communicate with one another using the SNMP are termed SNMP
  363.    application entities.  The peer processes which implement the SNMP,
  364.    and thus support the SNMP application entities, are termed protocol
  365.    entities.
  366.  
  367.    A pairing of an SNMP agent with some arbitrary set of SNMP
  368.    application entities is called an SNMP community.  Each SNMP
  369.    community is named by a string of octets, that is called the
  370.    community name for said community.
  371.  
  372.    An SNMP message originated by an SNMP application entity that in fact
  373.    belongs to the SNMP community named by the community component of
  374.    said message is called an authentic SNMP message.  The set of rules
  375.    by which an SNMP message is identified as an authentic SNMP message
  376.    for a particular SNMP community is called an authentication scheme.
  377.    An implementation of a function that identifies authentic SNMP
  378.    messages according to one or more authentication schemes is called an
  379.    authentication service.
  380.  
  381.    Clearly, effective management of administrative relationships among
  382.    SNMP application entities requires authentication services that (by
  383.    the use of encryption or other techniques) are able to identify
  384.    authentic SNMP messages with a high degree of certainty.  Some SNMP
  385.    implementations may wish to support only a trivial authentication
  386.    service that identifies all SNMP messages as authentic SNMP messages.
  387.  
  388.    For any network element, a subset of objects in the MIB that pertain
  389.    to that element is called a SNMP MIB view.  Note that the names of
  390.    the object types represented in a SNMP MIB view need not belong to a
  391.  
  392.  
  393.  
  394. Case, Fedor, Schoffstall, & Davin                               [Page 7]
  395.  
  396. RFC 1067                          SNMP                       August 1988
  397.  
  398.  
  399.    single sub-tree of the object type name space.
  400.  
  401.    An element of the set { READ-ONLY, READ-WRITE } is called an SNMP
  402.    access mode.
  403.  
  404.    A pairing of a SNMP access mode with a SNMP MIB view is called an
  405.    SNMP community profile.  A SNMP community profile represents
  406.    specified access privileges to variables in a specified MIB view. For
  407.    every variable in the MIB view in a given SNMP community profile,
  408.    access to that variable is represented by the profile according to
  409.    the following conventions:
  410.  
  411.       (1)  if said variable is defined in the MIB with "Access:" of
  412.            "none," it is unavailable as an operand for any operator;
  413.  
  414.       (2)  if said variable is defined in the MIB with "Access:" of
  415.            "read-write" or "write-only" and the access mode of the
  416.            given profile is READ-WRITE, that variable is available
  417.            as an operand for the get, set, and trap operations;
  418.  
  419.       (3)  otherwise, the variable is available as an operand for
  420.            the get and trap operations.
  421.  
  422.       (4)  In those cases where a "write-only" variable is an
  423.            operand used for the get or trap operations, the value
  424.            given for the variable is implementation-specific.
  425.  
  426.    A pairing of a SNMP community with a SNMP community profile is called
  427.    a SNMP access policy. An access policy represents a specified
  428.    community profile afforded by the SNMP agent of a specified SNMP
  429.    community to other members of that community.  All administrative
  430.    relationships among SNMP application entities are architecturally
  431.    defined in terms of SNMP access policies.
  432.  
  433.    For every SNMP access policy, if the network element on which the
  434.    SNMP agent for the specified SNMP community resides is not that to
  435.    which the MIB view for the specified profile pertains, then that
  436.    policy is called a SNMP proxy access policy. The SNMP agent
  437.    associated with a proxy access policy is called a SNMP proxy agent.
  438.    While careless definition of proxy access policies can result in
  439.    management loops, prudent definition of proxy policies is useful in
  440.    at least two ways:
  441.  
  442.       (1)  It permits the monitoring and control of network elements
  443.            which are otherwise not addressable using the management
  444.            protocol and the transport protocol.  That is, a proxy
  445.            agent may provide a protocol conversion function allowing
  446.            a management station to apply a consistent management
  447.  
  448.  
  449.  
  450. Case, Fedor, Schoffstall, & Davin                               [Page 8]
  451.  
  452. RFC 1067                          SNMP                       August 1988
  453.  
  454.  
  455.            framework to all network elements, including devices such
  456.            as modems, multiplexors, and other devices which support
  457.            different management frameworks.
  458.  
  459.       (2)  It potentially shields network elements from elaborate
  460.            access control policies.  For example, a proxy agent may
  461.            implement sophisticated access control whereby diverse
  462.            subsets of variables within the MIB are made accessible
  463.            to different management stations without increasing the
  464.            complexity of the network element.
  465.  
  466.    By way of example, Figure 1 illustrates the relationship between
  467.    management stations, proxy agents, and management agents.  In this
  468.    example, the proxy agent is envisioned to be a normal Internet
  469.    Network Operations Center (INOC) of some administrative domain which
  470.    has a standard managerial relationship with a set of management
  471.    agents.
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Case, Fedor, Schoffstall, & Davin                               [Page 9]
  507.  
  508. RFC 1067                          SNMP                       August 1988
  509.  
  510.  
  511.    +------------------+       +----------------+      +----------------+
  512.    |  Region #1 INOC  |       |Region #2 INOC  |      |PC in Region #3 |
  513.    |                  |       |                |      |                |
  514.    |Domain=Region #1  |       |Domain=Region #2|      |Domain=Region #3|
  515.    |CPU=super-mini-1  |       |CPU=super-mini-1|      |CPU=Clone-1     |
  516.    |PCommunity=pub    |       |PCommunity=pub  |      |PCommunity=slate|
  517.    |                  |       |                |      |                |
  518.    +------------------+       +----------------+      +----------------+
  519.           /|\                      /|\                     /|\
  520.            |                        |                       |
  521.            |                        |                       |
  522.            |                       \|/                      |
  523.            |               +-----------------+              |
  524.            +-------------->| Region #3 INOC  |<-------------+
  525.                            |                 |
  526.                            |Domain=Region #3 |
  527.                            |CPU=super-mini-2 |
  528.                            |PCommunity=pub,  |
  529.                            |         slate   |
  530.                            |DCommunity=secret|
  531.            +-------------->|                 |<-------------+
  532.            |               +-----------------+              |
  533.            |                       /|\                      |
  534.            |                        |                       |
  535.            |                        |                       |
  536.           \|/                      \|/                     \|/
  537.    +-----------------+     +-----------------+       +-----------------+
  538.    |Domain=Region#3  |     |Domain=Region#3  |       |Domain=Region#3  |
  539.    |CPU=router-1     |     |CPU=mainframe-1  |       |CPU=modem-1      |
  540.    |DCommunity=secret|     |DCommunity=secret|       |DCommunity=secret|
  541.    +-----------------+     +-----------------+       +-----------------+
  542.  
  543.  
  544.    Domain:  the administrative domain of the element
  545.    PCommunity:  the name of a community utilizing a proxy agent
  546.    DCommunity:  the name of a direct community
  547.  
  548.  
  549.                                  Figure 1
  550.                  Example Network Management Configuration
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Case, Fedor, Schoffstall, & Davin                              [Page 10]
  563.  
  564. RFC 1067                          SNMP                       August 1988
  565.  
  566.  
  567. 3.2.6.  Form and Meaning of References to Managed Objects
  568.  
  569.    The SMI requires that the definition of a conformant management
  570.    protocol address:
  571.  
  572.       (1)  the resolution of ambiguous MIB references,
  573.  
  574.       (2)  the resolution of MIB references in the presence multiple
  575.            MIB versions, and
  576.  
  577.       (3)  the identification of particular instances of object
  578.            types defined in the MIB.
  579.  
  580. 3.2.6.1.  Resolution of Ambiguous MIB References
  581.  
  582.    Because the scope of any SNMP operation is conceptually confined to
  583.    objects relevant to a single network element, and because all SNMP
  584.    references to MIB objects are (implicitly or explicitly) by unique
  585.    variable names, there is no possibility that any SNMP reference to
  586.    any object type defined in the MIB could resolve to multiple
  587.    instances of that type.
  588.  
  589. 3.2.6.2.  Resolution of References across MIB Versions
  590.  
  591.    The object instance referred to by any SNMP operation is exactly that
  592.    specified as part of the operation request or (in the case of a get-
  593.    next operation) its immediate successor in the MIB as a whole.  In
  594.    particular, a reference to an object as part of some version of the
  595.    Internet-standard MIB does not resolve to any object that is not part
  596.    of said version of the Internet-standard MIB, except in the case that
  597.    the requested operation is get-next and the specified object name is
  598.    lexicographically last among the names of all objects presented as
  599.    part of said version of the Internet-Standard MIB.
  600.  
  601. 3.2.6.3.  Identification of Object Instances
  602.  
  603.    The names for all object types in the MIB are defined explicitly
  604.    either in the Internet-standard MIB or in other documents which
  605.    conform to the naming conventions of the SMI.  The SMI requires that
  606.    conformant management protocols define mechanisms for identifying
  607.    individual instances of those object types for a particular network
  608.    element.
  609.  
  610.    Each instance of any object type defined in the MIB is identified in
  611.    SNMP operations by a unique name called its "variable name." In
  612.    general, the name of an SNMP variable is an OBJECT IDENTIFIER of the
  613.    form x.y, where x is the name of a non-aggregate object type defined
  614.    in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way
  615.  
  616.  
  617.  
  618. Case, Fedor, Schoffstall, & Davin                              [Page 11]
  619.  
  620. RFC 1067                          SNMP                       August 1988
  621.  
  622.  
  623.    specific to the named object type, identifies the desired instance.
  624.  
  625.    This naming strategy admits the fullest exploitation of the semantics
  626.    of the GetNextRequest-PDU (see Section 4), because it assigns names
  627.    for related variables so as to be contiguous in the lexicographical
  628.    ordering of all variable names known in the MIB.
  629.  
  630.    The type-specific naming of object instances is defined below for a
  631.    number of classes of object types.  Instances of an object type to
  632.    which none of the following naming conventions are applicable are
  633.    named by OBJECT IDENTIFIERs of the form x.0, where x is the name of
  634.    said object type in the MIB definition.
  635.  
  636.    For example, suppose one wanted to identify an instance of the
  637.    variable sysDescr The object class for sysDescr is:
  638.  
  639.              iso org dod internet mgmt mib system sysDescr
  640.               1   3   6     1      2    1    1       1
  641.  
  642.    Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is
  643.    appended an instance sub-identifier of 0.  That is, 1.3.6.1.2.1.1.1.0
  644.    identifies the one and only instance of sysDescr.
  645.  
  646. 3.2.6.3.1.  ifTable Object Type Names
  647.  
  648.    The name of a subnet interface, s, is the OBJECT IDENTIFIER value of
  649.    the form i, where i has the value of that instance of the ifIndex
  650.    object type associated with s.
  651.  
  652.    For each object type, t, for which the defined name, n, has a prefix
  653.    of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
  654.    the form n.s, where s is the name of the subnet interface about which
  655.    i represents information.
  656.  
  657.    For example, suppose one wanted to identify the instance of the
  658.    variable ifType associated with interface 2.  Accordingly, ifType.2
  659.    would identify the desired instance.
  660.  
  661. 3.2.6.3.2.  atTable Object Type Names
  662.  
  663.    The name of an AT-cached network address, x, is an OBJECT IDENTIFIER
  664.    of the form 1.a.b.c.d, where a.b.c.d is the value (in the familiar
  665.    "dot" notation) of the atNetAddress object type associated with x.
  666.  
  667.    The name of an address translation equivalence e is an OBJECT
  668.    IDENTIFIER value of the form s.w, such that s is the value of that
  669.    instance of the atIndex object type associated with e and such that w
  670.    is the name of the AT-cached network address associated with e.
  671.  
  672.  
  673.  
  674. Case, Fedor, Schoffstall, & Davin                              [Page 12]
  675.  
  676. RFC 1067                          SNMP                       August 1988
  677.  
  678.  
  679.    For each object type, t, for which the defined name, n, has a prefix
  680.    of atEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
  681.    the form n.y, where y is the name of the address translation
  682.    equivalence about which i represents information.
  683.  
  684.    For example, suppose one wanted to find the physical address of an
  685.    entry in the address translation table (ARP cache) associated with an
  686.    IP address of 89.1.1.42 and interface 3.  Accordingly,
  687.    atPhysAddress.3.1.89.1.1.42 would identify the desired instance.
  688.  
  689. 3.2.6.3.3.  ipAddrTable Object Type Names
  690.  
  691.    The name of an IP-addressable network element, x, is the OBJECT
  692.    IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the
  693.    familiar "dot" notation) of that instance of the ipAdEntAddr object
  694.    type associated with x.
  695.  
  696.    For each object type, t, for which the defined name, n, has a prefix
  697.    of ipAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER
  698.    of the form n.y, where y is the name of the IP-addressable network
  699.    element about which i represents information.
  700.  
  701.    For example, suppose one wanted to find the network mask of an entry
  702.    in the IP interface table associated with an IP address of 89.1.1.42.
  703.    Accordingly, ipAdEntNetMask.89.1.1.42 would identify the desired
  704.    instance.
  705.  
  706. 3.2.6.3.4.  ipRoutingTable Object Type Names
  707.  
  708.    The name of an IP route, x, is the OBJECT IDENTIFIER of the form
  709.    a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
  710.    notation) of that instance of the ipRouteDest object type associated
  711.    with x.
  712.  
  713.    For each object type, t, for which the defined name, n, has a prefix
  714.    of ipRoutingEntry, an instance, i, of t is named by an OBJECT
  715.    IDENTIFIER of the form n.y, where y is the name of the IP route about
  716.    which i represents information.
  717.  
  718.    For example, suppose one wanted to find the next hop of an entry in
  719.    the IP routing table associated  with the destination of 89.1.1.42.
  720.    Accordingly, ipRouteNextHop.89.1.1.42 would identify the desired
  721.    instance.
  722.  
  723. 3.2.6.3.5.  tcpConnTable Object Type Names
  724.  
  725.    The name of a TCP connection, x, is the OBJECT IDENTIFIER of the form
  726.    a.b.c.d.e.f.g.h.i.j such that a.b.c.d is the value (in the familiar
  727.  
  728.  
  729.  
  730. Case, Fedor, Schoffstall, & Davin                              [Page 13]
  731.  
  732. RFC 1067                          SNMP                       August 1988
  733.  
  734.  
  735.    "dot" notation) of that instance of the tcpConnLocalAddress object
  736.    type associated with x and such that f.g.h.i is the value (in the
  737.    familiar "dot" notation) of that instance of the tcpConnRemoteAddress
  738.    object type associated with x and such that e is the value of that
  739.    instance of the tcpConnLocalPort object type associated with x and
  740.    such that j is the value of that instance of the tcpConnRemotePort
  741.    object type associated with x.
  742.  
  743.    For each object type, t, for which the defined name, n, has a prefix
  744.    of  tcpConnEntry, an instance, i, of t is named by an OBJECT
  745.    IDENTIFIER of the form n.y, where y is the name of the TCP connection
  746.    about which i represents information.
  747.  
  748.    For example, suppose one wanted to find the state of a TCP connection
  749.    between the local address of 89.1.1.42 on TCP port 21 and the remote
  750.    address of 10.0.0.51 on TCP port 2059.  Accordingly,
  751.    tcpConnState.89.1.1.42.21.10.0.0.51.2059 would identify the desired
  752.    instance.
  753.  
  754. 3.2.6.3.6.  egpNeighTable Object Type Names
  755.  
  756.    The name of an EGP neighbor, x, is the OBJECT IDENTIFIER of the form
  757.    a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
  758.    notation) of that instance of the egpNeighAddr object type associated
  759.    with x.
  760.  
  761.    For each object type, t, for which the defined name, n, has a prefix
  762.    of egpNeighEntry, an instance, i, of t is named by an OBJECT
  763.    IDENTIFIER of the form n.y, where y is the name of the EGP neighbor
  764.    about which i represents information.
  765.  
  766.    For example, suppose one wanted to find the neighbor state for the IP
  767.    address of 89.1.1.42.  Accordingly, egpNeighState.89.1.1.42 would
  768.    identify the desired instance.
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Case, Fedor, Schoffstall, & Davin                              [Page 14]
  787.  
  788. RFC 1067                          SNMP                       August 1988
  789.  
  790.  
  791. 4.  Protocol Specification
  792.  
  793.    The network management protocol is an application protocol by which
  794.    the variables of an agent's MIB may be inspected or altered.
  795.  
  796.    Communication among protocol entities is accomplished by the exchange
  797.    of messages, each of which is entirely and independently represented
  798.    within a single UDP datagram using the basic encoding rules of ASN.1
  799.    (as discussed in Section 3.2.2).  A message consists of a version
  800.    identifier, an SNMP community name, and a protocol data unit (PDU).
  801.    A protocol entity receives messages at UDP port 161 on the host with
  802.    which it is associated for all messages except for those which report
  803.    traps (i.e., all messages except those which contain the Trap-PDU).
  804.    Messages which report traps should be received on UDP port 162 for
  805.    further processing.  An implementation of this protocol need not
  806.    accept messages whose length exceeds 484 octets.  However, it is
  807.    recommended that implementations support larger datagrams whenever
  808.    feasible.
  809.  
  810.    It is mandatory that all implementations of the SNMP support the five
  811.    PDUs: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU,
  812.    SetRequest-PDU, and Trap-PDU.
  813.  
  814.     RFC1067-SNMP DEFINITIONS ::= BEGIN
  815.  
  816.      IMPORTS
  817.           ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
  818.                   FROM RFC1065-SMI;
  819.  
  820.  
  821.      -- top-level message
  822.  
  823.              Message ::=
  824.                      SEQUENCE {
  825.                           version        -- version-1 for this RFC
  826.                              INTEGER {
  827.                                  version-1(0)
  828.                              },
  829.  
  830.                          community      -- community name
  831.                              OCTET STRING,
  832.  
  833.                          data           -- e.g., PDUs if trivial
  834.                              ANY        -- authentication is being used
  835.                      }
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Case, Fedor, Schoffstall, & Davin                              [Page 15]
  843.  
  844. RFC 1067                          SNMP                       August 1988
  845.  
  846.  
  847.      -- protocol data units
  848.  
  849.              PDUs ::=
  850.                      CHOICE {
  851.                          get-request
  852.                              GetRequest-PDU,
  853.  
  854.                          get-next-request
  855.                              GetNextRequest-PDU,
  856.  
  857.                          get-response
  858.                              GetResponse-PDU,
  859.  
  860.                          set-request
  861.                              SetRequest-PDU,
  862.  
  863.                          trap
  864.                              Trap-PDU
  865.                           }
  866.  
  867.      -- the individual PDUs and commonly used
  868.      -- data types will be defined later
  869.  
  870.      END
  871.  
  872.  
  873. 4.1.  Elements of Procedure
  874.  
  875.    This section describes the actions of a protocol entity implementing
  876.    the SNMP. Note, however, that it is not intended to constrain the
  877.    internal architecture of any conformant implementation.
  878.  
  879.    In the text that follows, the term transport address is used.  In the
  880.    case of the UDP, a transport address consists of an IP address along
  881.    with a UDP port.  Other transport services may be used to support the
  882.    SNMP.  In these cases, the definition of a transport address should
  883.    be made accordingly.
  884.  
  885.    The top-level actions of a protocol entity which generates a message
  886.    are as follows:
  887.  
  888.         (1)  It first constructs the appropriate PDU, e.g., the
  889.              GetRequest-PDU, as an ASN.1 object.
  890.  
  891.         (2)  It then passes this ASN.1 object along with a community
  892.              name its source transport address and the destination
  893.              transport address, to the service which implements the
  894.              desired authentication scheme.  This authentication
  895.  
  896.  
  897.  
  898. Case, Fedor, Schoffstall, & Davin                              [Page 16]
  899.  
  900. RFC 1067                          SNMP                       August 1988
  901.  
  902.  
  903.              service returns another ASN.1 object.
  904.  
  905.         (3)  The protocol entity then constructs an ASN.1 Message
  906.              object, using the community name and the resulting ASN.1
  907.              object.
  908.  
  909.         (4)  This new ASN.1 object is then serialized, using the basic
  910.              encoding rules of ASN.1, and then sent using a transport
  911.              service to the peer protocol entity.
  912.  
  913.    Similarly, the top-level actions of a protocol entity which receives
  914.    a message are as follows:
  915.  
  916.         (1)  It performs a rudimentary parse of the incoming datagram
  917.              to build an ASN.1 object corresponding to an ASN.1
  918.              Message object. If the parse fails, it discards the
  919.              datagram and performs no further actions.
  920.  
  921.         (2)  It then verifies the version number of the SNMP message.
  922.              If there is a mismatch, it discards the datagram and
  923.              performs no further actions.
  924.  
  925.         (3)  The protocol entity then passes the community name and
  926.              user data found in the ASN.1 Message object, along with
  927.              the datagram's source and destination transport addresses
  928.              to the service which implements the desired
  929.              authentication scheme.  This entity returns another ASN.1
  930.              object, or signals an authentication failure.  In the
  931.              latter case, the protocol entity notes this failure,
  932.              (possibly) generates a trap, and discards the datagram
  933.              and performs no further actions.
  934.  
  935.         (4)  The protocol entity then performs a rudimentary parse on
  936.              the ASN.1 object returned from the authentication service
  937.              to build an ASN.1 object corresponding to an ASN.1 PDUs
  938.              object.  If the parse fails, it discards the datagram and
  939.              performs no further actions.  Otherwise, using the named
  940.              SNMP community, the appropriate profile is selected, and
  941.              the PDU is processed accordingly.  If, as a result of
  942.              this processing, a message is returned then the source
  943.              transport address that the response message is sent from
  944.              shall be identical to the destination transport address
  945.              that the original request message was sent to.
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Case, Fedor, Schoffstall, & Davin                              [Page 17]
  955.  
  956. RFC 1067                          SNMP                       August 1988
  957.  
  958.  
  959. 4.1.1.  Common Constructs
  960.  
  961.    Before introducing the six PDU types of the protocol, it is
  962.    appropriate to consider some of the ASN.1 constructs used frequently:
  963.  
  964.                   -- request/response information
  965.  
  966.                   RequestID ::=
  967.                           INTEGER
  968.  
  969.                   ErrorStatus ::=
  970.                           INTEGER {
  971.                               noError(0),
  972.                               tooBig(1),
  973.                               noSuchName(2),
  974.                               badValue(3),
  975.                               readOnly(4)
  976.                               genErr(5)
  977.                           }
  978.  
  979.                   ErrorIndex ::=
  980.                           INTEGER
  981.  
  982.  
  983.                   -- variable bindings
  984.  
  985.                   VarBind ::=
  986.                           SEQUENCE {
  987.                               name
  988.                                   ObjectName,
  989.  
  990.                               value
  991.                                   ObjectSyntax
  992.                           }
  993.  
  994.                   VarBindList ::=
  995.                           SEQUENCE OF
  996.                               VarBind
  997.  
  998.  
  999.    RequestIDs are used to distinguish among outstanding requests.  By
  1000.    use of the RequestID, an SNMP application entity can correlate
  1001.    incoming responses with outstanding requests.  In cases where an
  1002.    unreliable datagram service is being used, the RequestID also
  1003.    provides a simple means of identifying messages duplicated by the
  1004.    network.
  1005.  
  1006.    A non-zero instance of ErrorStatus is used to indicate that an
  1007.  
  1008.  
  1009.  
  1010. Case, Fedor, Schoffstall, & Davin                              [Page 18]
  1011.  
  1012. RFC 1067                          SNMP                       August 1988
  1013.  
  1014.  
  1015.    exception occurred while processing a request.  In these cases,
  1016.    ErrorIndex may provide additional information by indicating which
  1017.    variable in a list caused the exception.
  1018.  
  1019.    The term variable refers to an instance of a managed object.  A
  1020.    variable binding, or VarBind, refers to the pairing of the name of a
  1021.    variable to the variable's value.  A VarBindList is a simple list of
  1022.    variable names and corresponding values.  Some PDUs are concerned
  1023.    only with the name of a variable and not its value (e.g., the
  1024.    GetRequest-PDU).  In this case, the value portion of the binding is
  1025.    ignored by the protocol entity.  However, the value portion must
  1026.    still have valid ASN.1 syntax and encoding.  It is recommended that
  1027.    the ASN.1 value NULL be used for the value portion of such bindings.
  1028.  
  1029. 4.1.2.  The GetRequest-PDU
  1030.  
  1031.              The form of the GetRequest-PDU is:
  1032.                   GetRequest-PDU ::=
  1033.                       [0]
  1034.                           IMPLICIT SEQUENCE {
  1035.                               request-id
  1036.                                   RequestID,
  1037.  
  1038.                               error-status        -- always 0
  1039.                                   ErrorStatus,
  1040.  
  1041.                               error-index         -- always 0
  1042.                                   ErrorIndex,
  1043.  
  1044.                               variable-bindings
  1045.                                   VarBindList
  1046.                           }
  1047.  
  1048.  
  1049.    The GetRequest-PDU is generated by a protocol entity only at the
  1050.    request of its SNMP application entity.
  1051.  
  1052.    Upon receipt of the GetRequest-PDU, the receiving protocol entity
  1053.    responds according to any applicable rule in the list below:
  1054.  
  1055.         (1)  If, for any object named in the variable-bindings field,
  1056.              the object's name does not exactly match the name of some
  1057.              object available for get operations in the relevant MIB
  1058.              view, then the receiving entity sends to the originator
  1059.              of the received message the GetResponse-PDU of identical
  1060.              form, except that the value of the error-status field is
  1061.              noSuchName, and the value of the error-index field is the
  1062.              index of said object name component in the received
  1063.  
  1064.  
  1065.  
  1066. Case, Fedor, Schoffstall, & Davin                              [Page 19]
  1067.  
  1068. RFC 1067                          SNMP                       August 1988
  1069.  
  1070.  
  1071.              message.
  1072.  
  1073.         (2)  If, for any object named in the variable-bindings field,
  1074.              the object is an aggregate type (as defined in the SMI),
  1075.              then the receiving entity sends to the originator of the
  1076.              received message the GetResponse-PDU of identical form,
  1077.              except that the value of the error-status field is
  1078.              noSuchName, and the value of the error-index field is the
  1079.              index of said object name component in the received
  1080.              message.
  1081.  
  1082.         (3)  If the size of the GetResponse-PDU generated as described
  1083.              below would exceed a local limitation, then the receiving
  1084.              entity sends to the originator of the received message
  1085.              the GetResponse-PDU of identical form, except that the
  1086.              value of the error-status field is tooBig, and the value
  1087.              of the error-index field is zero.
  1088.  
  1089.         (4)  If, for any object named in the variable-bindings field,
  1090.              the value of the object cannot be retrieved for reasons
  1091.              not covered by any of the foregoing rules, then the
  1092.              receiving entity sends to the originator of the received
  1093.              message the GetResponse-PDU of identical form, except
  1094.              that the value of the error-status field is genErr and
  1095.              the value of the error-index field is the index of said
  1096.              object name component in the received message.
  1097.  
  1098.    If none of the foregoing rules apply, then the receiving protocol
  1099.    entity sends to the originator of the received message the
  1100.    GetResponse-PDU such that, for each object named in the variable-
  1101.    bindings field of the received message, the corresponding component
  1102.    of the GetResponse-PDU represents the name and value of that
  1103.    variable.  The value of the error- status field of the GetResponse-
  1104.    PDU is noError and the value of the error-index field is zero.  The
  1105.    value of the request-id field of the GetResponse-PDU is that of the
  1106.    received message.
  1107.  
  1108. 4.1.3.  The GetNextRequest-PDU
  1109.  
  1110.    The form of the GetNextRequest-PDU is identical to that of the
  1111.    GetRequest-PDU except for the indication of the PDU type.  In the
  1112.    ASN.1 language:
  1113.  
  1114.                   GetNextRequest-PDU ::=
  1115.                       [1]
  1116.                           IMPLICIT SEQUENCE {
  1117.                               request-id
  1118.                                   RequestID,
  1119.  
  1120.  
  1121.  
  1122. Case, Fedor, Schoffstall, & Davin                              [Page 20]
  1123.  
  1124. RFC 1067                          SNMP                       August 1988
  1125.  
  1126.  
  1127.                               error-status        -- always 0
  1128.                                   ErrorStatus,
  1129.  
  1130.                               error-index         -- always 0
  1131.                                   ErrorIndex,
  1132.  
  1133.                               variable-bindings
  1134.                                   VarBindList
  1135.                           }
  1136.  
  1137.  
  1138.    The GetNextRequest-PDU is generated by a protocol entity only at the
  1139.    request of its SNMP application entity.
  1140.  
  1141.    Upon receipt of the GetNextRequest-PDU, the receiving protocol entity
  1142.    responds according to any applicable rule in the list below:
  1143.  
  1144.         (1)  If, for any object name in the variable-bindings field,
  1145.              that name does not lexicographically precede the name of
  1146.              some object available for get operations in the relevant
  1147.              MIB view, then the receiving entity sends to the
  1148.              originator of the received message the GetResponse-PDU of
  1149.              identical form, except that the value of the error-status
  1150.              field is noSuchName, and the value of the error-index
  1151.              field is the index of said object name component in the
  1152.              received message.
  1153.  
  1154.         (2)  If the size of the GetResponse-PDU generated as described
  1155.              below would exceed a local limitation, then the receiving
  1156.              entity sends to the originator of the received message
  1157.              the GetResponse-PDU of identical form, except that the
  1158.              value of the error-status field is tooBig, and the value
  1159.              of the error-index field is zero.
  1160.  
  1161.         (3)  If, for any object named in the variable-bindings field,
  1162.              the value of the lexicographical successor to the named
  1163.              object cannot be retrieved for reasons not covered by any
  1164.              of the foregoing rules, then the receiving entity sends
  1165.              to the originator of the received message the
  1166.              GetResponse-PDU of identical form, except that the value
  1167.              of the error-status field is genErr and the value of the
  1168.              error-index field is the index of said object name
  1169.              component in the received message.
  1170.  
  1171.    If none of the foregoing rules apply, then the receiving protocol
  1172.    entity sends to the originator of the received message the
  1173.    GetResponse-PDU such that, for each name in the variable-bindings
  1174.    field of the received message, the corresponding component of the
  1175.  
  1176.  
  1177.  
  1178. Case, Fedor, Schoffstall, & Davin                              [Page 21]
  1179.  
  1180. RFC 1067                          SNMP                       August 1988
  1181.  
  1182.  
  1183.    GetResponse-PDU represents the name and value of that object whose
  1184.    name is, in the lexicographical ordering of the names of all objects
  1185.    available for get operations in the relevant MIB view, together with
  1186.    the value of the name field of the given component, the immediate
  1187.    successor to that value.  The value of the error-status field of the
  1188.    GetResponse-PDU is noError and the value of the errorindex field is
  1189.    zero.  The value of the request-id field of the GetResponse-PDU is
  1190.    that of the received message.
  1191.  
  1192. 4.1.3.1.  Example of Table Traversal
  1193.  
  1194.    One important use of the GetNextRequest-PDU is the traversal of
  1195.    conceptual tables of information within the MIB. The semantics of
  1196.    this type of SNMP message, together with the protocol-specific
  1197.    mechanisms for identifying individual instances of object types in
  1198.    the MIB, affords  access to related objects in the MIB as if they
  1199.    enjoyed a tabular organization.
  1200.  
  1201.    By the SNMP exchange sketched below, an SNMP application entity might
  1202.    extract the destination address and next hop gateway for each entry
  1203.    in the routing table of a particular network element. Suppose that
  1204.    this routing table has three entries:
  1205.  
  1206.          Destination                     NextHop         Metric
  1207.  
  1208.          10.0.0.99                       89.1.1.42       5
  1209.          9.1.2.3                         99.0.0.3        3
  1210.          10.0.0.51                       89.1.1.42       5
  1211.  
  1212.  
  1213.    The management station sends to the SNMP agent a GetNextRequest-PDU
  1214.    containing the indicated OBJECT IDENTIFIER values as the requested
  1215.    variable names:
  1216.  
  1217.    GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
  1218.  
  1219.  
  1220.    The SNMP agent responds with a GetResponse-PDU:
  1221.  
  1222.                  GetResponse (( ipRouteDest.9.1.2.3 =  "9.1.2.3" ),
  1223.                          ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
  1224.                          ( ipRouteMetric1.9.1.2.3 = 3 ))
  1225.  
  1226.  
  1227.    The management station continues with:
  1228.  
  1229.                  GetNextRequest ( ipRouteDest.9.1.2.3,
  1230.                          ipRouteNextHop.9.1.2.3,
  1231.  
  1232.  
  1233.  
  1234. Case, Fedor, Schoffstall, & Davin                              [Page 22]
  1235.  
  1236. RFC 1067                          SNMP                       August 1988
  1237.  
  1238.  
  1239.                          ipRouteMetric1.9.1.2.3 )
  1240.  
  1241.  
  1242.    The SNMP agent responds:
  1243.  
  1244.                  GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
  1245.                          ( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
  1246.                          ( ipRouteMetric1.10.0.0.51 = 5 ))
  1247.  
  1248.  
  1249.    The management station continues with:
  1250.  
  1251.                  GetNextRequest ( ipRouteDest.10.0.0.51,
  1252.                          ipRouteNextHop.10.0.0.51,
  1253.                          ipRouteMetric1.10.0.0.51 )
  1254.  
  1255.  
  1256.    The SNMP agent responds:
  1257.  
  1258.                  GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
  1259.                          ( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
  1260.                          ( ipRouteMetric1.10.0.0.99 = 5 ))
  1261.  
  1262.  
  1263.    The management station continues with:
  1264.  
  1265.                  GetNextRequest ( ipRouteDest.10.0.0.99,
  1266.                          ipRouteNextHop.10.0.0.99,
  1267.                          ipRouteMetric1.10.0.0.99 )
  1268.  
  1269.  
  1270.    As there are no further entries in the table, the SNMP agent returns
  1271.    those objects that are next in the lexicographical ordering of the
  1272.    known object names.  This response signals the end of the routing
  1273.    table to the management station.
  1274.  
  1275. 4.1.4.  The GetResponse-PDU
  1276.  
  1277.    The form of the GetResponse-PDU is identical to that of the
  1278.    GetRequest-PDU except for the indication of the PDU type.  In the
  1279.    ASN.1 language:
  1280.  
  1281.                   GetResponse-PDU ::=
  1282.                       [2]
  1283.                           IMPLICIT SEQUENCE {
  1284.                               request-id
  1285.                                   RequestID,
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Case, Fedor, Schoffstall, & Davin                              [Page 23]
  1291.  
  1292. RFC 1067                          SNMP                       August 1988
  1293.  
  1294.  
  1295.                               error-status
  1296.                                   ErrorStatus,
  1297.  
  1298.                               error-index
  1299.                                   ErrorIndex,
  1300.  
  1301.                               variable-bindings
  1302.                                   VarBindList
  1303.                           }
  1304.  
  1305.  
  1306.    The GetResponse-PDU is generated by a protocol entity only upon
  1307.    receipt of the GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU,
  1308.    as described elsewhere in this document.
  1309.  
  1310.    Upon receipt of the GetResponse-PDU, the receiving protocol entity
  1311.    presents its contents to its SNMP application entity.
  1312.  
  1313. 4.1.5.  The SetRequest-PDU
  1314.  
  1315.    The form of the SetRequest-PDU is identical to that of the
  1316.    GetRequest-PDU except for the indication of the PDU type.  In the
  1317.    ASN.1 language:
  1318.  
  1319.                   SetRequest-PDU ::=
  1320.                       [3]
  1321.                           IMPLICIT SEQUENCE {
  1322.                               request-id
  1323.                                   RequestID,
  1324.  
  1325.                               error-status        -- always 0
  1326.                                   ErrorStatus,
  1327.  
  1328.                               error-index         -- always 0
  1329.                                   ErrorIndex,
  1330.  
  1331.                               variable-bindings
  1332.                                   VarBindList
  1333.                           }
  1334.  
  1335.  
  1336.    The SetRequest-PDU is generated by a protocol entity only at the
  1337.    request of its SNMP application entity.
  1338.  
  1339.    Upon receipt of the SetRequest-PDU, the receiving entity responds
  1340.    according to any applicable rule in the list below:
  1341.  
  1342.         (1)  If, for any object named in the variable-bindings field,
  1343.  
  1344.  
  1345.  
  1346. Case, Fedor, Schoffstall, & Davin                              [Page 24]
  1347.  
  1348. RFC 1067                          SNMP                       August 1988
  1349.  
  1350.  
  1351.              the object is not available for set operations in the
  1352.              relevant MIB view, then the receiving entity sends to the
  1353.              originator of the received message the GetResponse-PDU of
  1354.              identical form, except that the value of the error-status
  1355.              field is noSuchName, and the value of the error-index
  1356.              field is the index of said object name component in the
  1357.              received message.
  1358.  
  1359.         (2)  If, for any object named in the variable-bindings field,
  1360.              the contents of the value field does not, according to
  1361.              the ASN.1 language, manifest a type, length, and value
  1362.              that is consistent with that required for the variable,
  1363.              then the receiving entity sends to the originator of the
  1364.              received message the GetResponse-PDU of identical form,
  1365.              except that the value of the error-status field is
  1366.              badValue, and the value of the error-index field is the
  1367.              index of said object name in the received message.
  1368.  
  1369.         (3)  If the size of the Get Response type message generated as
  1370.              described below would exceed a local limitation, then the
  1371.              receiving entity sends to the originator of the received
  1372.              message the GetResponse-PDU of identical form, except
  1373.              that the value of the error-status field is tooBig, and
  1374.              the value of the error-index field is zero.
  1375.  
  1376.         (4)  If, for any object named in the variable-bindings field,
  1377.              the value of the named object cannot be altered for
  1378.              reasons not covered by any of the foregoing rules, then
  1379.              the receiving entity sends to the originator of the
  1380.              received message the GetResponse-PDU of identical form,
  1381.              except that the value of the error-status field is genErr
  1382.              and the value of the error-index field is the index of
  1383.              said object name component in the received message.
  1384.  
  1385.    If none of the foregoing rules apply, then for each object named in
  1386.    the variable-bindings field of the received message, the
  1387.    corresponding value is assigned to the variable.  Each variable
  1388.    assignment specified by the SetRequest-PDU should be effected as if
  1389.    simultaneously set with respect to all other assignments specified in
  1390.    the same message.
  1391.  
  1392.    The receiving entity then sends to the originator of the received
  1393.    message the GetResponse-PDU of identical form except that the value
  1394.    of the error-status field of the generated message is noError and the
  1395.    value of the error-index field is zero.
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Case, Fedor, Schoffstall, & Davin                              [Page 25]
  1403.  
  1404. RFC 1067                          SNMP                       August 1988
  1405.  
  1406.  
  1407. 4.1.6.  The Trap-PDU
  1408.  
  1409.    The form of the Trap-PDU is:
  1410.  
  1411.      Trap-PDU ::=
  1412.          [4]
  1413.  
  1414.               IMPLICIT SEQUENCE {
  1415.                  enterprise          -- type of object generating
  1416.                                      -- trap, see sysObjectID in [2]
  1417.                      OBJECT IDENTIFIER,
  1418.  
  1419.                  agent-addr          -- address of object generating
  1420.                      NetworkAddress, -- trap
  1421.  
  1422.                  generic-trap        -- generic trap type
  1423.                      INTEGER {
  1424.                          coldStart(0),
  1425.                          warmStart(1),
  1426.                          linkDown(2),
  1427.                          linkUp(3),
  1428.                          authenticationFailure(4),
  1429.                          egpNeighborLoss(5),
  1430.                          enterpriseSpecific(6)
  1431.                      },
  1432.  
  1433.                  specific-trap     -- specific code, present even
  1434.                      INTEGER,      -- if generic-trap is not
  1435.                                    -- enterpriseSpecific
  1436.  
  1437.                  time-stamp        -- time elapsed between the last
  1438.                    TimeTicks,      -- (re)initialization of the network
  1439.                                    -- entity and the generation of the
  1440.                                       trap
  1441.  
  1442.                  variable-bindings   -- "interesting" information
  1443.                       VarBindList
  1444.              }
  1445.  
  1446.  
  1447.    The Trap-PDU is generated by a protocol entity only at the request of
  1448.    the SNMP application entity.  The means by which an SNMP application
  1449.    entity selects the destination addresses of the SNMP application
  1450.    entities is implementation-specific.
  1451.  
  1452.    Upon receipt of the Trap-PDU, the receiving protocol entity presents
  1453.    its contents to its SNMP application entity.
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Case, Fedor, Schoffstall, & Davin                              [Page 26]
  1459.  
  1460. RFC 1067                          SNMP                       August 1988
  1461.  
  1462.  
  1463.    The significance of the variable-bindings component of the Trap-PDU
  1464.    is implementation-specific.
  1465.  
  1466.    Interpretations of the value of the generic-trap field are:
  1467.  
  1468. 4.1.6.1.  The coldStart Trap
  1469.  
  1470.    A coldStart(0) trap signifies that the sending protocol entity is
  1471.    reinitializing itself such that the agent's configuration or the
  1472.    protocol entity implementation may be altered.
  1473.  
  1474. 4.1.6.2.  The warmStart Trap
  1475.  
  1476.    A warmStart(1) trap signifies that the sending protocol entity is
  1477.    reinitializing itself such that neither the agent configuration nor
  1478.    the protocol entity implementation is altered.
  1479.  
  1480. 4.1.6.3.  The linkDown Trap
  1481.  
  1482.    A linkDown(2) trap signifies that the sending protocol entity
  1483.    recognizes a failure in one of the communication links represented in
  1484.    the agent's configuration.
  1485.  
  1486.    The Trap-PDU of type linkDown contains as the first element of its
  1487.    variable-bindings, the name and value of the ifIndex instance for the
  1488.    affected interface.
  1489.  
  1490. 4.1.6.4.  The linkUp Trap
  1491.  
  1492.    A linkUp(3) trap signifies that the sending protocol entity
  1493.    recognizes that one of the communication links represented in the
  1494.    agent's configuration has come up.
  1495.  
  1496.    The Trap-PDU of type linkUp contains as the first element of its
  1497.    variable-bindings, the name and value of the ifIndex instance for the
  1498.    affected interface.
  1499.  
  1500. 4.1.6.5.  The authenticationFailure Trap
  1501.  
  1502.    An authenticationFailure(4) trap signifies that the sending protocol
  1503.    entity is the addressee of a protocol message that is not properly
  1504.    authenticated.  While implementations of the SNMP must be capable of
  1505.    generating this trap, they must also be capable of suppressing the
  1506.    emission of such traps via an implementation-specific mechanism.
  1507.  
  1508. 4.1.6.6.  The egpNeighborLoss Trap
  1509.  
  1510.    An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
  1511.  
  1512.  
  1513.  
  1514. Case, Fedor, Schoffstall, & Davin                              [Page 27]
  1515.  
  1516. RFC 1067                          SNMP                       August 1988
  1517.  
  1518.  
  1519.    the sending protocol entity was an EGP peer has been marked down and
  1520.    the peer relationship no longer obtains.
  1521.  
  1522.    The Trap-PDU of type egpNeighborLoss contains as the first element of
  1523.    its variable-bindings, the name and value of the egpNeighAddr
  1524.    instance for the affected neighbor.
  1525.  
  1526. 4.1.6.7.  The enterpriseSpecific Trap
  1527.  
  1528.    A enterpriseSpecific(6) trap signifies that the sending protocol
  1529.    entity recognizes that some enterprise-specific event has occurred.
  1530.    The specific-trap field identifies the particular trap which
  1531.    occurred.
  1532.  
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  
  1539.  
  1540.  
  1541.  
  1542.  
  1543.  
  1544.  
  1545.  
  1546.  
  1547.  
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Case, Fedor, Schoffstall, & Davin                              [Page 28]
  1571.  
  1572. RFC 1067                          SNMP                       August 1988
  1573.  
  1574.  
  1575. 5.  Definitions
  1576.  
  1577.      RFC1067-SNMP DEFINITIONS ::= BEGIN
  1578.  
  1579.       IMPORTS
  1580.           ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
  1581.               FROM RFC1065-SMI;
  1582.  
  1583.  
  1584.           -- top-level message
  1585.  
  1586.           Message ::=
  1587.                   SEQUENCE {
  1588.                       version          -- version-1 for this RFC
  1589.                           INTEGER {
  1590.                               version-1(0)
  1591.                           },
  1592.  
  1593.                       community        -- community name
  1594.                           OCTET STRING,
  1595.  
  1596.                       data             -- e.g., PDUs if trivial
  1597.                           ANY          -- authentication is being used
  1598.                   }
  1599.  
  1600.  
  1601.           -- protocol data units
  1602.  
  1603.           PDUs ::=
  1604.                   CHOICE {
  1605.                               get-request
  1606.                                   GetRequest-PDU,
  1607.  
  1608.                               get-next-request
  1609.                                   GetNextRequest-PDU,
  1610.  
  1611.                               get-response
  1612.                                   GetResponse-PDU,
  1613.  
  1614.                               set-request
  1615.                                   SetRequest-PDU,
  1616.  
  1617.                               trap
  1618.                                   Trap-PDU
  1619.                           }
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. Case, Fedor, Schoffstall, & Davin                              [Page 29]
  1627.  
  1628. RFC 1067                          SNMP                       August 1988
  1629.  
  1630.  
  1631.           -- PDUs
  1632.  
  1633.           GetRequest-PDU ::=
  1634.               [0]
  1635.                   IMPLICIT PDU
  1636.  
  1637.           GetNextRequest-PDU ::=
  1638.               [1]
  1639.                   IMPLICIT PDU
  1640.  
  1641.           GetResponse-PDU ::=
  1642.               [2]
  1643.                   IMPLICIT PDU
  1644.  
  1645.           SetRequest-PDU ::=
  1646.               [3]
  1647.                   IMPLICIT PDU
  1648.  
  1649.           PDU ::=
  1650.                   SEQUENCE {
  1651.                      request-id
  1652.                           INTEGER,
  1653.  
  1654.                       error-status      -- sometimes ignored
  1655.                           INTEGER {
  1656.                               noError(0),
  1657.                               tooBig(1),
  1658.                               noSuchName(2),
  1659.                               badValue(3),
  1660.                               readOnly(4),
  1661.                               genErr(5)
  1662.                           },
  1663.  
  1664.                       error-index       -- sometimes ignored
  1665.                          INTEGER,
  1666.  
  1667.                       variable-bindings -- values are sometimes ignored
  1668.                           VarBindList
  1669.                   }
  1670.  
  1671.           Trap-PDU ::=
  1672.               [4]
  1673.                  IMPLICIT SEQUENCE {
  1674.                       enterprise        -- type of object generating
  1675.                                         -- trap, see sysObjectID in [2]
  1676.  
  1677.  
  1678.                           OBJECT IDENTIFIER,
  1679.  
  1680.  
  1681.  
  1682. Case, Fedor, Schoffstall, & Davin                              [Page 30]
  1683.  
  1684. RFC 1067                          SNMP                       August 1988
  1685.  
  1686.  
  1687.                       agent-addr        -- address of object generating
  1688.                           NetworkAddress, -- trap
  1689.  
  1690.                       generic-trap      -- generic trap type
  1691.                           INTEGER {
  1692.                               coldStart(0),
  1693.                               warmStart(1),
  1694.                               linkDown(2),
  1695.                               linkUp(3),
  1696.                               authenticationFailure(4),
  1697.                               egpNeighborLoss(5),
  1698.                               enterpriseSpecific(6)
  1699.                           },
  1700.  
  1701.                       specific-trap  -- specific code, present even
  1702.                           INTEGER,   -- if generic-trap is not
  1703.                                      -- enterpriseSpecific
  1704.  
  1705.                       time-stamp     -- time elapsed between the last
  1706.                           TimeTicks, -- (re)initialization of the
  1707.                                         network
  1708.                                      -- entity and the generation of the
  1709.                                         trap
  1710.  
  1711.                        variable-bindings -- "interesting" information
  1712.                           VarBindList
  1713.                   }
  1714.  
  1715.  
  1716.           -- variable bindings
  1717.  
  1718.           VarBind ::=
  1719.                   SEQUENCE {
  1720.                       name
  1721.                           ObjectName,
  1722.  
  1723.                       value
  1724.                           ObjectSyntax
  1725.                   }
  1726.  
  1727.          VarBindList ::=
  1728.                   SEQUENCE OF
  1729.                      VarBind
  1730.  
  1731.          END
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Case, Fedor, Schoffstall, & Davin                              [Page 31]
  1739.  
  1740. RFC 1067                          SNMP                       August 1988
  1741.  
  1742.  
  1743. 6.  Acknowledgements
  1744.  
  1745.    This memo was influenced by the IETF SNMP Extensions working
  1746.    group:
  1747.  
  1748.              Karl Auerbach, Epilogue Technology
  1749.              K. Ramesh Babu, Excelan
  1750.              Amatzia Ben-Artzi, 3Com/Bridge
  1751.              Lawrence Besaw, Hewlett-Packard
  1752.              Jeffrey D. Case, University of Tennessee at Knoxville
  1753.              Anthony Chung, Sytek
  1754.              James Davidson, The Wollongong Group
  1755.              James R. Davin, Proteon
  1756.              Mark S. Fedor, NYSERNet
  1757.              Phill Gross, The MITRE Corporation
  1758.              Satish Joshi, ACC
  1759.              Dan Lynch, Advanced Computing Environments
  1760.              Keith McCloghrie, The Wollongong Group
  1761.              Marshall T. Rose, The Wollongong Group (chair)
  1762.              Greg Satz, cisco
  1763.              Martin Lee Schoffstall, Rensselaer Polytechnic Institute
  1764.              Wengyik Yeong, NYSERNet
  1765.  
  1766.  
  1767.  
  1768.  
  1769.  
  1770.  
  1771.  
  1772.  
  1773.  
  1774.  
  1775.  
  1776.  
  1777.  
  1778.  
  1779.  
  1780.  
  1781.  
  1782.  
  1783.  
  1784.  
  1785.  
  1786.  
  1787.  
  1788.  
  1789.  
  1790.  
  1791.  
  1792.  
  1793.  
  1794. Case, Fedor, Schoffstall, & Davin                              [Page 32]
  1795.  
  1796. RFC 1067                          SNMP                       August 1988
  1797.  
  1798.  
  1799. 7.  References
  1800.  
  1801.    [1] Cerf, V., "IAB Recommendations for the Development of
  1802.        Internet Network Management Standards", RFC 1052, IAB,
  1803.        April 1988.
  1804.  
  1805.    [2] Rose, M., and K. McCloghrie, "Structure and Identification
  1806.        of Management Information for TCP/IP-based internets",
  1807.        RFC 1065, TWG, August 1988.
  1808.  
  1809.    [3] McCloghrie, K., and M. Rose, "Management Information Base
  1810.        for Network Management of TCP/IP-based internets",
  1811.        RFC 1066, TWG, August 1988.
  1812.  
  1813.    [4] Case, J., M. Fedor, M. Schoffstall, and J. Davin,
  1814.        "A Simple Network Management Protocol", Internet
  1815.        Engineering Task Force working note, Network Information
  1816.        Center, SRI International, Menlo Park, California,
  1817.        March 1988.
  1818.  
  1819.    [5] Davin, J., J. Case, M. Fedor, and M. Schoffstall,
  1820.        "A Simple Gateway Monitoring Protocol", RFC 1028,
  1821.        Proteon, University of Tennessee at Knoxville,
  1822.        Cornell University, and Rensselaer Polytechnic
  1823.        Institute, November 1987.
  1824.  
  1825.    [6] Information processing systems - Open Systems
  1826.        Interconnection, "Specification of Abstract Syntax
  1827.        Notation One (ASN.1)", International Organization for
  1828.        Standardization, International Standard 8824,
  1829.        December 1987.
  1830.  
  1831.    [7] Information processing systems - Open Systems
  1832.        Interconnection, "Specification of Basic Encoding Rules
  1833.        for Abstract Notation One (ASN.1)", International
  1834.        Organization for Standardization, International Standard
  1835.        8825, December 1987.
  1836.  
  1837.    [8] Postel, J., "User Datagram Protocol", RFC 768,
  1838.        USC/Information Sciences Institute, November 1980.
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850. Case, Fedor, Schoffstall, & Davin                              [Page 33]
  1851.